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DETAILED ACTION 

1 . This Office Action is in response to the Request for Reconsideration after Non- 
Final Rejection filed 08/01/2008. Claims 1-5, 1 1 , 13, 14, 18-24 and 31-42 are pending 
and have been examined. 

Declaration Under 37 C.F.R. 1.131 

2. The declaration filed on 08/01/2008 under 37 CFR 1 .131 has been considered 
but is ineffective to overcome the McCoskey et al. reference (US 2003/0028889). 

3. The evidence submitted is insufficient to establish invention of the subject matter 
of the rejected claims prior to the effective date of the reference because the declaration 
was made by less than all the named inventors without showing that less than all 
named inventors invented the claims under rejection. An affidavit or declaration by less 
than all named inventors of an application is accepted where it is shown that less than 
all named inventors of an application invented the subject matter of the claim or claims 
under rejection. For example, one of two joint inventors is accepted where it is shown 
that one of the joint inventors is the sole inventor of the claim or claims under rejection. 
See MPEP§ 715.04. 

Claim Rejections - 35 USC § 103 

4. The following is a quotation of 35 U.S.C. 1 03(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 
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5. Claims 1-5, 11, 13, 14, 18-24 and 37 are rejected under 35 U.S.C. 103(a) as 

being unpatentable over McCoskey et al. (US Patent Application Publication 

2003/0028889), McCoskey, in view of Ogawa et al. (US Patent 6,314,571), Ogawa. 

Consider claim 1, McCoskey clearly teaches a system providing video on 
demand services from a plurality of incompatible and non-interoperable VOD 
systems. (Fig. 1: The system 200 provides VOD services from a plurality of 
incompatible devices, [0045]) 

receiving a request from a receiver station for all currently available VOD 
assets; (A programming search request is created and sent by the 
user, [0086]. The search criteria may be set so as to return all 
available content.) 

transmitting to each of the plurality of incompatible VOD systems a 
request for a respective list of all currently available VOD assets; (Fig. 4: 
Search engine server 350 periodically requests information on all 
available programming from the remote sources, [0065]) 

aggregating the translated lists of all currently available VOD assets to 
form a combined list of available VOD assets, the combined list of 
available VOD assets being adapted to be compatible with a plurality of 
receiver stations. (Fig. 10: Aggregator local database 501 contains the 
remote content database 261 which stores a catalog of all content 
stored in each of the remote databases, [0079]-[0080].) 

McCoskey further teaches receiving all currently available VOD assets, in 
response to the request for the assets. (Remote content crawler 356 retrieves 
all information about all content not previously logged, [0065]) 

However, McCoskey does not explicitly teach each received list being formatted 
in a unique protocol and translating the received lists into a generic protocol. 

In an analogous art Ogawa, which discloses a system for collecting information 
stored in separate systems and transmitting a combined list of all assets, clearly 
teaches receiving the lists in different protocols and translating the lists into a 
generic protocol. (Fig. 6: The EPG data collection and delivery center 1 
receives EPG data from a plurality of sources in different formats and data 
converting section 14 converts the data into a generic format and stores 
the data in the transmitting-data storing section 131, column 10 lines 53- 
67.) 
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Therefore, at the time the invention was made, it would have been obvious to 
one with ordinary skill in the art to modify the system of McCoskey by receiving 
the lists in different formats and translating them into a generic format, as taught 
by Ogawa, for the benefit of providing updated information to the users without 
changing individual system configurations (see column 2 lines 31-42 Ogawa). 



Consider claim 2, McCoskey and Ogawa, combined as in claim 1, clearly teach, 
after receiving a request for content from a user (Fig. 15b: In step 712 the user 
requests content then in step 715 the request is sent to the aggregator 201, 
[0103] McCoskey.), performing the following steps: 

identifying which VOD system is associated with the requested VOD asset 
via the received list of all currently available VOD assets from one of the 
plurality of incompatible VOD systems; (Fig. 16a: In step 759 the 
metadata associated with the requested content is analyzed to 
determine the storage location of the content, [0106] McCoskey.) 

transmitting, to the identified VOD system, a compatible request for the 
VOD asset; (Fig. 16b: In step 762 the remote content server 204 is 
notified of the request, [0107] McCoskey.) 

receiving the requested VOD asset from the identified VOD system; (Fig. 
17a: In step 804 the requested content is transmitted to the 
aggregator 201, [0109] McCoskey.) 

adapting the received VOD asset to be compatible with the requesting 
receiver station; (Fig. 17b: In steps 812 and 813 the content is 
formatted to the required format, [0111] McCoskey.) 

transacting for the requested VOD asset with the requesting receiver 
station and the identified VOD system. (Fig. 17c: If billing or fees are 
applicable routine 830 enters the user, content meta data and 
content provider into the billing process 900, [0117 McCoskey.]) 



Consider claims 3, 14, 21, 22, 23, 24, 33, 34, 35 and 36, McCoskey and Ogawa, 
combined as in claims 1, 13, 20 and 32, clearly teach the requested VOD asset 
may be a video program, audio program, electronic book (text) or multimedia 
(graphic). ([0043] McCoskey) 

Consider claim 4, McCoskey and Ogawa, combined as in claim 1 , clearly teach 
each VOD system contains an asset management system for managing 
respective assets (Fig. 16b: The remote servers use routine 763 to control 
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the dissemination of the content, [0107] McCoskey.) and a business 
management system for managing transactions. (Aggregator 201 negotiates 
fees with content providers and distributes compensation to the content 
providers, [0123] McCoskey.) The VOD asset management system is 
communicated with via an asset gateway. (Fig. 4: Content acquisition server 
400 requests content from the remote servers, [0060] McCoskey.) The 
business management system is transacted with using a transaction gateway. 
(Fig. 10: Content fee and copyright billing server 507 communicates with 
the business management system of the content providers, [0123] 
McCoskey.) 

Consider claim 5, McCoskey and Ogawa, combined as in claim 1, clearly teach 
providing the desired asset to the receiver using either digital storage command 
and control or real time streaming protocol. (The content may be streamed to 
the user or delivered and stored by the user for later playback, [0116] 
McCoskey.) 



Consider claim 11, McCoskey clearly teaches a system providing video on 
demand services from a plurality of incompatible and non-interoperable VOD 
systems. (Fig. 1 : The system 200 provides VOD services from a plurality of 
incompatible devices, [0045]) 

transmitting to each of the plurality of incompatible VOD systems a 
request for a respective list of all currently available VOD assets; (Fig. 4: 
Search engine server 350 periodically requests information on all 
available programming from the remote sources, [0065]) 

aggregating the translated lists of all currently available VOD assets to 
form a combined list of available VOD assets, the combined list of 
available VOD assets being adapted to be compatible with a plurality of 
receiver stations. (Fig. 10: Aggregator local database 501 contains the 
remote content database 261 which stores a catalog of all content 
stored in each of the remote databases, [0079]-[0080].) 

receiving a request from a receiver station for a VOD asset; (Fig. 15b: In 
step 712 the user requests content then in step 715 the request is 
sent to the aggregator 201, [0103] McCoskey.) 

in response to a request from a receiver station for a VOD asset, performing the 
following steps: 

identifying which VOD system is associated with the requested VOD asset 
via the received list of all currently available VOD assets from one of the 
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plurality of incompatible VOD systems; (Fig. 16a: In step 759 the 
metadata associated with the requested content is analyzed to 
determine the storage location of the content, [0106] McCoskey.) 

transmitting, to the identified VOD system, a compatible request for the 

VOD asset; (Fig. 16b: In step 762 the remote content server 204 is 

notified of the request, [0107] McCoskey.) 



receiving the requested VOD asset from the identified VOD system; (Fig. 
17a: In step 804 the requested content is transmitted to the 
aggregator 201, [0109] McCoskey.) 

adapting the received VOD asset to be compatible with the requesting 
receiver station; (Fig. 17b: In steps 812 and 813 the content is 
formatted to the required format, [0111] McCoskey.) 

transacting for the requested VOD asset with the requesting receiver 
station and the identified VOD system. (Fig. 17c: If billing or fees are 
applicable routine 830 enters the user, content meta data and 
content provider into the billing process 900, [0117] McCoskey.) 

McCoskey further teaches receiving all currently available VOD assets, in 
response to the request for the assets. (Remote content crawler 356 retrieves 
all information about all content not previously logged, [0065]) 

However, McCoskey does not explicitly teach each received list being formatted 
in a unique protocol and translating the received lists into a generic protocol. 

In an analogous art Ogawa, which discloses a system for collecting information 
stored in separate systems and transmitting a combined list of all assets, clearly 
teaches receiving the lists in different protocols and translating the lists into a 
generic protocol. (Fig. 6: The EPG data collection and delivery center 1 
receives EPG data from a plurality of sources in different formats and data 
converting section 14 converts the data into a generic format and stores 
the data in the transmitting-data storing section 131, column 10 lines 53- 
67.) 

Therefore, at the time the invention was made, it would have been obvious to 
one with ordinary skill in the art to modify the system of McCoskey by receiving 
the lists in different formats and translating them into a generic format, as taught 
by Ogawa, for the benefit of providing updated information to the users without 
changing individual system configurations (see column 2 lines 31-42 Ogawa). 
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Consider claims 13, 20 and 32, McCoskey and Ogawa, combined as in claims 
11,19 and 31 , clearly teach each VOD system includes a business management 
system. (Aggregator 201 negotiates fees with content providers and 
distributes compensation to the content providers, [0123] McCoskey.) 
When a program is received at the receiving station an event is recorded 
showing a purchase of that program. (Fig. 10: When content is downloaded 
the content delivery server 450 logs the event with database administrator 
502, [0126] McCoskey.) The purchase event is then transmitted from the VOD 
gateway to the corresponding business management system. (Fig. 10: Content 
fee and copyright billing server 507 transmits compensation to the content 
providers, [0123] McCoskey.) 



Consider claims 18, 19 and 31, McCoskey clearly teaches a system, having a 
transmitting station including a gateway server (Fig. 2 Aggregator 201) and a 
receiving station including a generic client (Fig. 2 Set top terminal 206), 
providing video on demand services from a plurality of incompatible and non- 
interoperable VOD systems. (Fig. 1: The system 200 provides VOD services 
from a plurality of incompatible devices, [0045] - [0046]) Each VOD system 
having an asset management system. (Fig. 16b: The remote servers use 
routine 763 to control the dissemination of the content, [0107] McCoskey.) 

receiving a request from a receiver station for all currently available VOD 
assets; (A programming search request is created and sent by the 
user, [0086]. The search criteria may be set so as to return all 
available content.) 

transmitting a request from said VOD gateway to said first and second 
VOD asset management system for a first and second list of all currently 
available VOD assets stored in said first and second VOD system. (Fig. 4: 
Search engine server 350 periodically requests information on all 
available programming from the remote sources, [0065]) 

aggregating the first and second translated lists of all currently available 
VOD assets to form a combined list of available VOD assets. (Fig. 10: 
Aggregator local database 501 contains the remote content database 
261 which stores a catalog of all content stored in each of the remote 
databases, [0079]-[0080].) 

transmitting from the receiving station to the gateway server a request for 
a list of VOD assets. (Fig. 13a: Routine 613 sends a search request to 
the aggregator 201, [0089].) 
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transmitting the combined list of VOD assets from the gateway to the 
receiver. (Fig. 14b: Routine 671 sends the list of content to the user 
terminal, [0100].) 

receiving a request from a receiver station for a VOD asset (Fig. 15b: In 
step 712 the user requests content then in step 715 the request is 
sent to the aggregator 201, [0103] McCoskey.) 

determining which VOD server contains the requested content via the 
received first and second lists of all available content (Fig. 16a: In step 
759 the metadata associated with the requested content is analyzed 
to determine the storage location of the content, [0106] McCoskey.) 

forwarding the request to the specified first or second VOD server (Fig. 

16b: In step 762 the remote content server 204 is notified of the 

request, [0107] McCoskey.) 



receiving the requested VOD asset from the identified VOD system; (Fig. 
17a: In step 804 the requested content is transmitted to the 
aggregator 201, [0109] McCoskey.) 

McCoskey further teaches receiving all currently available VOD assets, in 
response to the request for the assets. (Remote content crawler 356 retrieves 
all information about all content not previously logged, [0065]) 

However, McCoskey does not explicitly teach each received list being formatted 
in a unique protocol and translating the received lists into a generic protocol. 

In an analogous art Ogawa, which discloses a system for collecting information 
stored in separate systems and transmitting a combined list of all assets, clearly 
teaches receiving the lists in different protocols and translating the lists into a 
generic protocol. (Fig. 6: The EPG data collection and delivery center 1 
receives EPG data from a plurality of sources in different formats and data 
converting section 14 converts the data into a generic format and stores 
the data in the transmitting-data storing section 131, column 10 lines 53- 
67.) 

Therefore, at the time the invention was made, it would have been obvious to 
one with ordinary skill in the art to modify the system of McCoskey by receiving 
the lists in different formats and translating them into a generic format, as taught 
by Ogawa, for the benefit of providing updated information to the users without 
changing individual system configurations (see column 2 lines 31-42 Ogawa). 
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Consider claim 37, McCoskey clearly teaches a video on demand gateway 
enabling the delivery of VOD services to subscriber equipment from a plurality of 
incompatible and non-interoperable VOD systems. (Fig. 1: The system 200 
provides VOD services to subscriber terminals from a plurality of 
incompatible devices, [0045]) 
The VOD gateway comprising: 

an asset gateway, for providing a unified list of VOD assets from the 
received lists of all currently available VOD assets. (Remote content 
crawler 356 retrieves all information about all content not previously 
logged, [0065]. Fig. 10: Aggregator local database 501 contains the 
remote content database 261 which stores a catalog of all content 
stored in each of the remote databases, [0079]-[0080].) 

a transaction gateway, for conforming communications into the 
appropriate format from the subscriber to the appropriate VOD system and 
from the VOD system to the subscriber. (Fig. 15b user download 
request is sent to the aggregator. The aggregator then translates 
and routes the request to the remote server, Fig. 16b step 762. The 
remote server then transmits the requested content to the 
aggregator, Fig. 17a step 804. The content is then reformatted, Fig. 
17b step 813, and transmitted to the user terminal, Fig. 17c step 826.) 

However, McCoskey does not explicitly teach translating received lists, each in a 
unique protocol, from each of the incompatible VOD systems. 

In an analogous art Ogawa, which discloses a system for collecting information 
stored in separate systems and transmitting a combined list of all assets, clearly 
teaches receiving the lists in different protocols and translating the lists into a 
generic protocol. (Fig. 6: The EPG data collection and delivery center 1 
receives EPG data from a plurality of sources in different formats and data 
converting section 14 converts the data into a generic format and stores 
the data in the transmitting-data storing section 131, column 10 lines 53- 
67.) 

Therefore, at the time the invention was made, it would have been obvious to 
one with ordinary skill in the art to modify the system of McCoskey by receiving 
the lists in different formats and translating them into a generic format, as taught 
by Ogawa, for the benefit of providing updated information to the users without 
changing individual system configurations (see column 2 lines 31-42 Ogawa). 
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6. Claims 38-41 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
McCoskey et al. (US Patent Application Publication 2003/0028889) in view of 
Ogawa et al. (US Patent 6,314,571), as applied to claims 1 and 37 above, and further 
in view of Bowman-Amuah (US Patent 6,434,568). 



Consider claim 38, McCoskey and Ogawa, combined as in claim 37, clearly 
teach the asset gateway communicating with the transaction gateway (Fig. 16a: 
The users request is transferred to routine 762 where it is encrypted for 
communication to the remote servers, [0107] McCoskey.) and an asset data 
manager which communicates with each asset management system via a 
respective interface program. (Fig. 7: Search engine server 350 
communicates with each VOD system to retrieve content information, 
[0065] McCoskey. The use of respective interface programs is inherently 
disclosed in order for search engine server to communicate with the 
incompatible remote servers.) 

However, McCoskey and Ogawa do not explicitly teach the use of a servlet and 
application programming interfaces. 

In an analogous art Bowman-Amuah, which discloses a system for transmission 
of data across a network, clearly teaches the use of a servlet (Java applet, 
ActiveX, column 15 lines 42-57) and application programming interfaces, 
(column 52 lines 49-63) 

Therefore, at the time the invention was made, it would have been obvious to 
one with ordinary skill in the art to modify the system of McCoskey and Ogawa by 
utilizing a servlet or API, as taught by Bowman-Amuah, for the benefit of 
providing a more secure, architecture neutral, platform independent, portable, 
flexible and easier to develop system (see column 15 lines 50-57 and column 52 
lines 52-56 Bowman-Amuah). 

Consider claim 39, McCoskey and Ogawa, combined as in claim 37, clearly 
teach the transaction gateway communicating with each business management 
system (BMS) via a respective BMS program. (Fig. 10: Content fee and 
copyright billing server 507 communicates with the business management 
system of the content providers, [0123] McCoskey.) 

However, McCoskey and Ogawa do not explicitly teach the use of application 
programming interfaces. It would have been obvious to modify the system of 
McCoskey and Ogawa with Bowman-Amuah as shown in claim 38. 
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Consider claim 40, McCoskey and Ogawa, combined as in claim 37, clearly 
teach the VOD gateway includes a database for storing client transaction 
information. (Fig. 11 User database server 511, [0079] McCoskey) 



Consider claim 41, McCoskey and Ogawa, combined as in claim 37, clearly 
teach a session gateway communicating with each VOD manager via respective 
session interface programs. (Fig. 16b: Routine 762 routes the request for the 
content to the correct remote server, [0107] McCoskey. The use of 
respective session interface programs is inherent, see claim 38.) 

However, McCoskey and Ogawa do not explicitly teach the use of application 
programming interfaces. It would have been obvious to modify the system of 
McCoskey and Ogawa with Bowman-Amuah as shown in claim 38. 

7. Claim 42 is rejected under 35 U.S.C. 103(a) as being unpatentable over 

McCoskey et al. (US Patent Application Publication 2003/0028889) in view of 

Ogawa et al. (US Patent 6,314,571) in view of Bowman-Amuah (US Patent 

6,434,568), as applied to claim 41 above, and further in view of Burkhart (US Patent 

Application Publication 2002/0006116). 



Consider claim 42, McCoskey, Ogawa and Bowman-Amuah, combined 
as in claim 41 , clearly teach the VOD gateway of claim 41 . 

However, McCoskey, Ogawa and Bowman-Amuah do not explicitly teach each 
VOD manager determines channel parameters associated with a subscriber 
request. 

In an analogous art Burkhart, which discloses a system aggregation of content, 
clearly teaches each VOD manager determines channel parameters associated 
with a subscriber request. ([0027], [0030], [0032] lines 1-21) The session 
gateway communicating VOD channel parameters to the subscriber using one of 
Session Resource Management ([0030], [0032] lines 7-15) and Session set up 
protocol. ([0027], [0030], [0032] lines 33-45) 

Therefore, at the time the invention was made, it would have been obvious to 
one with ordinary skill in the art to modify the system of McCoskey, Ogawa and 
Bowman-Amuah by determining channel parameters associated with subscriber 
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requests and communicating them via SRM or SSP, as taught by Burkhart, for 
the benefit of providing users with information needed to obtain the content (see 
[0032] Burkhart). 

Conclusion 

8. THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time 
policy as set forth in 37 CFR 1 .136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within 
TWO MONTHS of the mailing date of this final action and the advisory action is not 
mailed until after the end of the THREE-MONTH shortened statutory period, then the 
shortened statutory period will expire on the date the advisory action is mailed, and any 
extension fee pursuant to 37 CFR 1 .136(a) will be calculated from the mailing date of 
the advisory action. In no event, however, will the statutory period for reply expire later 
than SIX MONTHS from the mailing date of this final action. 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to JOHN R. SCHNURR whose telephone number is 
(571)270-1458. The examiner can normally be reached on Monday - Friday, 8:00am to 
5:30pm. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, John W. Miller can be reached on (571) 272-7353. The fax phone number 
for the organization where this application or proceeding is assigned is 571-273-8300. 
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Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a 
USPTO Customer Service Representative or access to the automated information 
system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 

/John W. Miller/ 

Supervisory Patent Examiner, Art Unit 2421 
JRS 



